Hi Justin,

If SP waits during initialization, there's two possibilities:

1. The paquet SP sent to LFS never arrived to LFS.
   
2. The paquet arrived to LFS but LFS ignored it and doesn't send the answer paquet SP is waiting.
   

If 1, desactivate all your firewalls, or check port numbers.
If 2, check if LFS is really listening at the port set with the /insim [port number] command. When you press the initialize button, you should see the following message in LFS: "InSim - UDP : Sans Plomb 2.0 (port 801)".

I don't know exactly what is LFS Relax, but I think you probably need a relay.

Quote from zonda722 :

if u think its so pathetic then stop reading it not hard is it

We just have to read it one time to be disgusted by some aspect of LFS community.

Please trash this thread now, all these worthless fights for points of view about a single car release make me sick
The only thing useful to do is to wait, nothing else can erase frustrations, so no need to talk about it.

Raise the AO samples number, but this will make the render longer.

It's normal since AO only generates shadows in this scene. Re-activate it

The black background is actually transparent, open the render in an image editor and add a layer under it (of white, landscape image...)

forget this thread, there was a problem in my program, my results are now correct and LFS rulez

DCS Black Shark
http://www.digitalcombatsimula ... 950&scr=default〈=en

OK detailed procedure:

• In the garage screen, with FBM selected, default setup selected, press O key to generate a bin file
  
• With a home-made program, retrieve aero data from the bin file according to the documentation:
  Quote :

  // Now 4 aero blocks - rear wing, front wing,
  undertray, body : 20 bytes each)
  
  128 Position : x, y, z
  Lift : multiply by speed squared to get lift value
  Drag : multiply by speed squared to get drag value
  
  
  
• Then for each drag and lift value, multiply it with speed squared
  
• Speed is assumed to be in m/s and resulted values in Newton.
  

Hi all

I'm playing with the CAR_info.bin files feature of LFS. I already made successful works with suspension data contained in those files.
Now I'm working with aerodynamics and I found something interesting when I tried to get aero results matching LFS's ones:

What LFS says about aero forces for the FBM with default setup at 60m/s windspeed:

Rear wing:
Lift= -859 N, Drag= 202 N

Front wing:
Lift= -753 N, Drag= 122 N

Undertray:
Lift= -1440 N, Drag= 360 N

Body:
Lift= 0 N, Drag= 720 N

Total lift= -3052 N
Total drag= 1405 N

Now here are my results:

Rear wing:
Lift= -1673 N, Drag= 184 N

Front wing:
Lift= -1804 N, Drag= 165 N

Undertray:
Lift= -3456 N, Drag= 576 N

Body:
Lift= 0 N, Drag= 900 N

Total lift= -6932 N
Total drag= 1825 N

I'm quite puzzled with this, but the bin file format doc says:

Quote :

multiply by speed squared to get lift value

OK my values seem to be correctly calculated but so much difference...

Does someone already experienced this?
Did I made a mistake?
Is LFS wrong?

EDIT: yes I made a mistake

Last edited by Bogey Jammer, Fri, 27 Mar 2009 11:00. Reason : problem solved.

Almost two years after the beginning of the project, I finally managed to do it.
I'm late, very late but happy now

The V2.0 version of Sans Plomb is out and does everything as planned :yipee:

Enjoy!

Personnally I harden the springs until the car is too uncontrollable, it depends on the track conditions too, so an unique spring frequency per car for every track is not suggested. Furthermore the correct term is "natural frequency" which seems to be calculated without dampers interaction.

AFAIK the high spring freqs noticed in elite competition cars are due to the pilot's alien skills, and compensation for high side wall dimensions effects of the F1 cars for example.

The best way to work with MoTeC interpreter for LFS is to convert a .raf file to a .ld file.
Actually it is possible, but to activate the pro-mode into this file (in order to enjoy the great features of MoTeC interpreter :razz, you have to hack this file structure.
I contacted the Rfactor motec plugin creator and he told me that since the rights about this file structure are not clear (officials from Motec corp don't want to talk about it), he won't give the file structure and Motec use in pro mode for LFS should be home-made for personal use only.

AirOne tes copies de nfs et co n'ont rien à foutre dans ce topic

The model had probably a mirror modifier. Remove all the edges of an half of the car then apply the mirror modifier to get perfect symmetry edition.

Quote from T.J. :

But why is 3DS Max so much faster then? Does it have a better render engine?

What are you talking about? 3DSmax is not a render engine but a 3D modeler. How many times will I repeat that?

Yes it looks quite good, seems to use the same basics as the V1 kit. Just one sun, probably an hemi lamp, specular desactivated, a simple background image.. but about the rims I don't know exactly, they are textured but I don't see clearly what are the other settings. They are nice rendered anyway.
The scene is fine tuned and I agree that it's quick to render but you have to admit that there's a lack of shadows. There's almost no depth on the car. That's the price for a quick render.

There's not any magic in rendering. If you want realistic results you have to wait longer. Sometimes I waited 80 hours to finish some renders. But you can still tweak a scene to deactivate some parameters or to replace them with another less greedy.
The V1 kit uses cheap features like an hemi light, a simple sun and simple materials.
The V2 kit uses ambient occlusion, a reflective floor an glossy material for rims. All of these are very thirsty.

Ok I delete this thread, it's clearly obsolete now anyway...

You can do everything else but working with Blender another project.
I feel the rendering speed slows down if the render window is minimized but I don't confirmed it yet.

Nice render BTW, the V1 kit suits well the background image with the big white specular shades on the cars. According to the image shadows, the light source seems to come more from the upper-back direction.

So we'll discuss back about it in 2-3 years, CUDA is not developed enough and renderers must be rewritten to be compatible.

Quote from T.J. :

It should be a option enable the GPU for faster renders.. I will buy a core i7 soon though so I don`t care really xD Maybe I`ll go back to blender again

If there's no option to render with GPU, it's probably because it's impossible (or too hard to make it compatible with so much GPU species). Most of renderer don't do that (actually I think no one does that).

There's probably a safety setting in your router that prevents the guest info to your pc. An embedded firewall?
Has your Vista's firewall disabled?

The graphic card is not used while rendering, CPU only.